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REMARKS 

Claims 1-14 stand rejected under 35 U.S.C. § 103(a) as being obvious over U.S. Patent 
6,434,649 to Baker et al. (hereinafter, Baker), in view of U.S. Patent Application Publication 
2003/0126056 to Hausman et al. (hereinafter, Hausman) and further in view of U.S. Patent No. 
5,983,270 to Abraham et al. (hereinafter, Abraham). 

Claim 1 is amended to recite that the streaming data is " non-field delineated data " and 
that the data engine is arrange to " recognize the record and field structure of the non-field 
delineated data. " Support for these amendments may be found, at least, in paragraph [0015] of 
Applicants' published application. 

Claim 8 is amended to address the objections raised by the Examiner by providing proper 
antecedent basis for the element "an output FIFO write pointer" and clarifying that "prior fields 
in the output tuple are discarded." Support for these amendments may be found, at least, in 
paragraph [0122] of Applicants' published application. 

Claim 9 is amended to address the objections raised by the Examiner by providing proper 
antecedent basis for the element "an overflow filter bit" and clarifying that it is "inserted in a 
length field appended to the output tuple ." Support for these amendments may be found, at least, 
in paragraph [0129] of Applicants' published application. 

Claim 1 1 is amended to address the objections raised by the Examiner by clarifying that 
" the results of TIP processing indicate that a tuple is to be returned ." Support for this 
amendment may be found, at least, in paragraph [0127] of Applicants' published application. 

Following entry of the above amendments, Applicants will have overcome all objections 
and rejections and believe all claims are in condition for allowance. Therefore, Applicants 
respectfully request reconsideration and withdrawal of all rejections under 35 U.S.C § 103(a). 

Without limitation to the claims, example embodiments of the present invention relate to 
a Programmable Streaming Data Processor (PSDP) which is arranged to perform primitive 
functions directly on non-field delineated data received from a streaming data source prior to its 
being forwarded to a microprocessor of a more general purpose Job Processing Unit (JPU). A 
data engine included in the PSDP may be programmed to recognize the record and field 
structures of the non-field delineated data. The data engine then parses non-field delineated data 
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into field delineated data and examines fields of a record using logical arithmetic methods to 
determine whether a record will or will not be passed to the CPU of the JPU as an output tuple. 
An output tuple is then formed comprised of the fields of the source record of the disc that are to 
be selected for further processing by the CPU and PSDP. 

Baker relates to a data processor, and more specifically to a data transfer arrangement 
mechanism employed to transfer data to various components within a data processor. One such 
data transfer arrangement is directed to processing computer graphics and graphics on a 
standalone gaming console. 

Hausman relates to distribution of financial data. Users of terminals in a computer 
system select data from feeds provided over a network. The data may be used in data-requesting 
programs accessed at the terminals. Data identified for distribution to applications are mapped 
into forms as specified by the users. 

Abraham relates to a method of network management in which a filter executive 
optimizes policies into a set of rules for respective users. A filter engine filters data packets 
outbound from the network and applies the rules to all data packets inbound to the network. The 
filter executive stores transaction records for each packet, including filter results, such as 
allow/deny. 

However, the Examiner has not set forth a prima facie case that the Applicants' claims 
are obvious. Baker, Hausman and Abraham, individually or in combination, do not disclose or 
suggest all of the elements of Applicants' Claim 1 . Applicants also do not agree that one of 
ordinary skill in the art would be motivated to combine the references as suggested by the 
Examiner. 

The combination of Baker, Hausman and Abraham is not configured to recognize the record and 
field structure of non-field delineated data 

The combination of Baker, Hausman and Abraham is neither arranged to " recognize the 

record and field structure of non-field delineated data " nor "determine field boundaries in the 

non-field delineated data " as required by Applicants' Claim 1, as amended. As described in 

paragraph [0015] of Applicants' published application: 

. . .the PSDP can parse non-field-delineated, streaming data from 
the [streaming data source] into block header fields, record header 
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fields, and record data fields , . . In other words, the PSDP can be 
programmed to understand the record and field structure of the 
data which the analysis software running on the CPU of the JPU 
wishes to analyze . Therefore, the PSDP can further process data in 
the specific format of the database application. (Emphasis added.) 

The Examiner has likened Applicants' claimed data engine to the application 

programming interface (API) 104 in Hausman. However, the data received by Hausman's API is 

already field-delineated . As described in paragraph [0045] of Hausman with relation to data 

from source 101 received through queue 108: 

API 104 reviews data records included within the stream [received 
from source 101 through queue 1081... and selects . . . data records 
requested by users served by the API. (Emphasis added.) 

This interpretation of Hausman is actually supported by the Examiner's admission at the bottom 
of page 2 of the Advisory Action dated July 28, 2008 that "the output data [as received by API 
104 from queue 108] includes delimiters between records and between elements within the 
records ." (Emphasis added.) Thus, the data received by Hausman's API 104 is, indeed, field- 
delineated. 

Further, there is certainly no teaching in Hausman, or any other cited reference, of a data 
engine arranged to " recognize the record and field structure of the non-field delineated data ." 
Likewise, although the Examiner looks to paragraph [0039] of Hausman for a determination of 
field boundaries, the insertion of delimiters between records and between elements within the 
records as taught in paragraph [0039] makes it clear that delimiters are inserted at the data stream 
source 101, and not at the API 104. In fact, the data stream source 101 in Hausman is well 
upstream of the API 104 at the client server 105. Therefore, Hausman's API neither is arranged 
to " recognize the record and field structure of the non-field delineated data " nor "determine field 
boundaries in the non-field delineated data ." 

The combination of Baker, Hausman and Abraham neither selects fields to be assembled into 
output tuples nor assembles fields into tuples 

The combination of Baker, Hausman and Abraham neither selects fields to be assembled 
into output tuples nor assembles fields into tuples as required by Applicants' Claim 1. As 
described in paragraph [0108] of Applicants' published application, the term "tuple" is used by 
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Applicants for the purpose of differentiating "raw" disk 23 record formats from PSDP 28 output 
record formats. For example, paragraph [0019] of Applicants 5 published application teaches that 
an output tuple "is comprised of the fields of the source record from the disk that are to be 
selected for further processing by the CPU and PSDP generated fields ." 

The Examiner has likened Hausman's API 104 to Applicants' claimed data engine. 
However, as described in paragraph [0045] of Hausman, the API 104 " selects. . .data records 
requested by users served by the API" (emphasis added) and passes complete records to clients 
requesting them . Thus, Hausman describes wholesale selection by the API 1 04 of entire 
requested records (i.e.. raw data), and not selection of particular fields of those records as 
recognized in the non-field delineated data by the data engine (i.e., an output tuple comprised of 
the fields of the source record from the disk that are to be selected for further processing by the 
CPU and PSDP generated fields). Moreover, by the Examiner's own admission, "according to 
[0045], only the records that are requested by the users are sent to that particular user [JPU] for 
processing." (Emphasis added.) These records are the same as the records from the source. 
They are not comprised of field selected for further processing. Hausman has no teaching, 
mention or even a suggestion of tuples as required by Applicants' claims. 

During examination, the claims must be interpreted as broadly as their terms reasonably 
allow. However, the claims are not read in a vacuum, but in light of the specification to which 
they pertain. When the specification of a patent application explicitly states the meaning that a 
term in the claim is intended to have, the claim is examined using that meaning, in order to 
achieve a complete exploration of the applicant's invention and its relation to the prior art. 

Therefore, the Examiner's interpretation of the claim term "tuple" is unjustified. Given 
the explicit intended meaning of the term recited in paragraphs [0019] and [0108] of Applicants' 
published application, equating both a tuple and a record to a "row" of data is inconsistent. 

It then stands that Hausman also does not assemble fields into an output tuple as required 
by Applicants' Claim 1 . As emphasized above, an output tuple "is comprised of the fields... that 
are to be selected for further processing by the CPU and PSDP generated fields " (paragraph 
[0019] of Applicants' published application). These selected fields, plus those assembled by the 
claimed tuple generator, do not equate to a row of raw data from the data source as asserted by 
the Examiner. Rather, they comprise a new data form (i.e., a tuple) generated by the tuple 
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generator of the PSDP. A row of data, as in Hausman, equates to a database record but does not 
equate to a tuple. Therefore, Hausman also fails to teach assembling fields into output tuples . 

It would not be obvious to combine the teachings of Baker and Hausman 

The Examiner states on page 6 of the Office Action that it would have been obvious to 

one of ordinary skill in the art at the time of the invention was made to combine Hausman' s 

method of filtering data as a subcomponent to Baker's data streamer because "it is well known to 

one of ordinary skill that filtering provides customized distribution of data and also decreases 

that the (sic) amount of information sent across the network." In the Advisory Action on page 3, 

the Examiner further states, as motivation to combine the references: 

In this case [in Hausman], the data is being sent across a network and 
therefore reducing the amount of information of data would reduce for 
example, the required bandwidth. The results of decreasing the amount 
of data sent across a network are well known in the art. 

While the Examiner's assertion is true with respect to the teachings of Hausman, which 
sends data over a network from the client server 105 to application terminals 106, one of 
ordinary skill in the art would not be so motivated to combine Baker and Hausman. Baker 
relates to a data processor, and more specifically to a data transfer arrangement mechanism 
employed to transfer data to various components within that very same data processor . Although 
Baker does discuss bandwidth requirements between particular input/output (I/O) devices, this is 
in context to supporting data transfers between endpoints that exhibit mismatched or varying 
bandwidth requirements within a data processor , and has nothing to do with reducing bandwidth 
requirements over a network as in Hausman. Therefore, because there is no network in Baker in 
which bandwidth requirements may be reduced, one of ordinary skill in the art would not look to 
combine the Baker and Hausman references. 

It would not be obvious to combine the teachings of Baker, Hausman and Abraham 

The proposed modification of Baker and Hausman by Abraham would render Baker 
unsatisfactory for its intended purpose. The Examiner states, as motivation for such as 
combination, that "One would have been motivated to do so in order to increase efficiency by 
limiting the amount of information transferred." However, quite to the contrary, one of ordinary 
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skill in the art would not be motivated to combine Baker, Housman and Abraham because the 
combination would render Baker unsatisfactory for its intended purpose. According to MPEP § 
2143.01(I)(V): 

If proposed modification would render the prior art invention being 
modified unsatisfactory for its intended purpose , then there is no 
suggestion or motivation to make the proposed modification (emphasis 
added). 

In this case, by combining the Baker, Hausman and Abraham references, as suggested by the 
Examiner, the Baker system fails for its intended purpose. 

Specifically. Baker's data streamer is employed for predetermined data movements 
within a multimedia processor (col. 5, lines 58-59). That is, Baker's data streamer specifically 
supports data transfer between memory or I/O devices within the same processor . Thus, one 
skilled in the art would not be motivated to combine the network data bandwidth reduction of 
Abraham, produced by its packet filtering, with the data streamer of Baker because Baker, as 
modified by Abraham (i.e., filtering out packets), would fail to deliver all data from the source , 
such as the memory. Baker would then fail to properly transfer data to the various internal 
components of the data processor. 

Accordingly, the proposed modification by Abraham renders Baker unsatisfactory for its 
intended purpose. That is, Baker's providing of buffered data movements within a multimedia 
processor cannot be executed by using the reduction in transmitted data provided by the IP paket 
filtering taught in Abraham. 

It is thus respectfully submitted that the Examiner neither has shown where in the prior 
art references each of the elements of Claim 1 is found nor presented a valid motivation for 
combining the references. The combination of Baker, Hausman and Abraham does not 
overcome any of the deficiencies of Baker. Because the Office Action is so deficient, and fails 
to clearly articulate the reason(s) why the claimed invention would have been obvious, the Office 
Action fails to set out a prima facie case of obviousness. Further, all other Claims 2-14 depend 
from independent Claim 1 and contain all the elements of the base claim. At least for this reason 
these claims are thus nonobvious as well. 



Information Disclosure Statement 

An Information Disclosure Statement (IDS) is being filed concurrently herewith. Entry 
of the IDS is respectfully requested. 

CONCLUSION 

In view of the above amendments and remarks, it is believed that all claims are in 
condition for allowance, and it is respectfully requested that the application be passed to issue. If 
the Examiner feels that a telephone conference would expedite prosecution of this case, the 
Examiner is invited to call the undersigned. 

Respectfully submitted, 

HAMILTON, BROOK, SMITH & REYNOLDS, P.C 
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